home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1653 < prev    next >
Text File  |  1995-07-26  |  18KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               J. Klensin, WG Chair
  8. Request for Comments: 1653                                           MCI
  9. Obsoletes: 1427                                         N. Freed, Editor
  10. Category: Standards Track                                       Innosoft
  11.                                                                 K. Moore
  12.                                                  University of Tennessee
  13.                                                                July 1994
  14.  
  15.  
  16.           SMTP Service Extension for Message Size Declaration
  17.  
  18. Status of this Memo
  19.  
  20.    This document specifies an Internet standards track protocol for the
  21.    Internet community, and requests discussion and suggestions for
  22.    improvements.  Please refer to the current edition of the "Internet
  23.    Official Protocol Standards" (STD 1) for the standardization state
  24.    and status of this protocol.  Distribution of this memo is unlimited.
  25.  
  26. Abstract
  27.  
  28.    This memo defines an extension to the SMTP service whereby an SMTP
  29.    client and server may interact to give the server an opportunity to
  30.    decline to accept a message (perhaps temporarily) based on the
  31.    client's estimate of the message size.
  32.  
  33. 1.  Introduction
  34.  
  35.    The MIME extensions to the Internet message protocol provide for the
  36.    transmission of many kinds of data which were previously unsupported
  37.    in Internet mail.  One expected result of the use of MIME is that
  38.    SMTP will be expected to carry a much wider range of message sizes
  39.    than was previously the case.  This has an impact on the amount of
  40.    resources (e.g., disk space) required by a system acting as a server.
  41.  
  42.    This memo uses the mechanism defined in [5] to define extensions to
  43.    the SMTP service whereby a client ("sender-SMTP") may declare the
  44.    size of a particular message to a server ("receiver-SMTP"), after
  45.    which the server may indicate to the client that it is or is not
  46.    willing to accept the message based on the declared message size and
  47.    whereby a server ("receiver-SMTP") may declare the maximum message
  48.    size it is willing to accept to a client ("sender-SMTP").
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Klensin, Freed & Moore                                          [Page 1]
  59.  
  60. RFC 1653                 SMTP Size Declaration                 July 1994
  61.  
  62.  
  63. 2.  Framework for the Size Declaration Extension
  64.  
  65.    The following service extension is therefore defined:
  66.  
  67.    (1) the name of the SMTP service extension is "Message Size
  68.        Declaration";
  69.  
  70.    (2) the EHLO keyword value associated with this extension is "SIZE";
  71.  
  72.    (3) one optional parameter is allowed with this EHLO keyword value,
  73.        a decimal number indicating the fixed maximum message size in
  74.        bytes that the server will accept.  The syntax of the parameter
  75.        is as follows, using the augmented BNF notation of [2]:
  76.  
  77.            size-param ::= [1*DIGIT]
  78.  
  79.        A parameter value of 0 (zero) indicates that no fixed maximum
  80.        message size is in force.  If the parameter is omitted no
  81.        information is conveyed about the server's fixed maximum message
  82.        size;
  83.  
  84.    (4) one optional parameter using the keyword "SIZE" is added to the
  85.        MAIL FROM command.  The value associated with this parameter is a
  86.        decimal number indicating the size of the message that is to be
  87.        transmitted.  The syntax of the value is as follows, using the
  88.        augmented BNF notation of [2]:
  89.  
  90.            size-value ::= 1*DIGIT
  91.  
  92.    (5) no additional SMTP verbs are defined by this extension.
  93.  
  94.    The remainder of this memo specifies how support for the extension
  95.    affects the behavior of an SMTP client and server.
  96.  
  97. 3.  The Message Size Declaration service extension
  98.  
  99.    An SMTP server may have a fixed upper limit on message size.  Any
  100.    attempt by a client to transfer a message which is larger than this
  101.    fixed upper limit will fail.  In addition, a server normally has
  102.    limited space with which to store incoming messages.  Transfer of a
  103.    message may therefore also fail due to a lack of storage space, but
  104.    might succeed at a later time.
  105.  
  106.    A client using the unextended SMTP protocol defined in [1], can only
  107.    be informed of such failures after transmitting the entire message to
  108.    the server (which discards the transferred message).  If, however,
  109.    both client and server support the Message Size Declaration service
  110.    extension, such conditions may be detected before any transfer is
  111.  
  112.  
  113.  
  114. Klensin, Freed & Moore                                          [Page 2]
  115.  
  116. RFC 1653                 SMTP Size Declaration                 July 1994
  117.  
  118.  
  119.    attempted.
  120.  
  121.    An SMTP client wishing to relay a large content may issue the EHLO
  122.    command to start an SMTP session, to determine if the server supports
  123.    any of several service extensions.  If the server responds with code
  124.    250 to the EHLO command, and the response includes the EHLO keyword
  125.    value SIZE, then the Message Size Declaration extension is supported.
  126.  
  127.    If a numeric parameter follows the SIZE keyword value of the EHLO
  128.    response, it indicates the size of the largest message that the
  129.    server is willing to accept.  Any attempt by a client to transfer a
  130.    message which is larger than this limit will be rejected with a
  131.    permanent failure (552) reply code.
  132.  
  133.    A server that supports the Message Size Declaration extension will
  134.    accept the extended version of the MAIL command described below.
  135.    When supported by the server, a client may use the extended MAIL
  136.    command (instead of the MAIL command as defined in [1]) to declare an
  137.    estimate of the size of a message it wishes to transfer.  The server
  138.    may then return an appropriate error code if it determines that an
  139.    attempt to transfer a message of that size would fail.
  140.  
  141. 4.  Definitions
  142.  
  143.    The message size is defined as the number of octets, including CR-LF
  144.    pairs, but not the SMTP DATA command's terminating dot or doubled
  145.    quoting dots, to be transmitted by the SMTP client after receiving
  146.    reply code 354 to the DATA command.
  147.  
  148.    The fixed maximum message size is defined as the message size of the
  149.    largest message that a server is ever willing to accept.  An attempt
  150.    to transfer any message larger than the fixed maximum message size
  151.    will always fail.  The fixed maximum message size may be an
  152.    implementation artifact of the SMTP server, or it may be chosen by
  153.    the administrator of the server.
  154.  
  155.    The declared message size is defined as a client's estimate of the
  156.    message size for a particular message.
  157.  
  158. 4.  The extended MAIL command
  159.  
  160.    The extended MAIL command is issued by a client when it wishes to
  161.    inform a server of the size of the message to be sent.  The extended
  162.    MAIL command is identical to the MAIL command as defined in [1],
  163.    except that a SIZE parameter appears after the address.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Klensin, Freed & Moore                                          [Page 3]
  171.  
  172. RFC 1653                 SMTP Size Declaration                 July 1994
  173.  
  174.  
  175.    The complete syntax of this extended command is defined in [5]. The
  176.    esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
  177.    the syntax for size-value shown above.
  178.  
  179.    The value associated with the SIZE parameter is a decimal
  180.    representation of the declared message size in octets.  This number
  181.    should include the message header, body, and the CR-LF sequences
  182.    between lines, but not the SMTP DATA command's terminating dot or
  183.    doubled quoting dots. Only one SIZE parameter may be specified in a
  184.    single MAIL command.
  185.  
  186.    Ideally, the declared message size is equal to the true message size.
  187.    However, since exact computation of the message size may be
  188.    infeasable, the client may use a heuristically-derived estimate.
  189.    Such heuristics should be chosen so that the declared message size is
  190.    usually larger than the actual message size. (This has the effect of
  191.    making the counting or non-counting of SMTP DATA dots largely an
  192.    academic point.)
  193.  
  194.    NOTE: Servers MUST NOT use the SIZE parameter to determine end of
  195.    content in the DATA command.
  196.  
  197. 5.1  Server action on receipt of the extended MAIL command
  198.  
  199.    Upon receipt of an extended MAIL command containing a SIZE parameter,
  200.    a server should determine whether the declared message size exceeds
  201.    its fixed maximum message size.  If the declared message size is
  202.    smaller than the fixed maximum message size, the server may also wish
  203.    to determine whether sufficient resources are available to buffer a
  204.    message of the declared message size and to maintain it in stable
  205.    storage, until the message can be delivered or relayed to each of its
  206.    recipients.
  207.  
  208.    A server may respond to the extended MAIL command with any of the
  209.    error codes defined in [1] for the MAIL command.  In addition, one of
  210.    the following error codes may be returned:
  211.  
  212.    (1) If the server currently lacks sufficient resources to accept a
  213.        message of the indicated size, but may be able to accept the
  214.        message at a later time, it responds with code "452
  215.        insufficient system storage".
  216.  
  217.    (2) If the indicated size is larger than the server's fixed maximum
  218.        message size, the server responds with code "552 message size
  219.        exceeds fixed maximium message size".
  220.  
  221.    A server is permitted, but not required, to accept a message which
  222.    is, in fact, larger than declared in the extended MAIL command, such
  223.  
  224.  
  225.  
  226. Klensin, Freed & Moore                                          [Page 4]
  227.  
  228. RFC 1653                 SMTP Size Declaration                 July 1994
  229.  
  230.  
  231.    as might occur if the client employed a size-estimation heuristic
  232.    which was inaccurate.
  233.  
  234. 5.2  Client action on receiving response to extended MAIL command
  235.  
  236.    The client, upon receiving the server's response to the extended MAIL
  237.    command, acts as follows:
  238.  
  239.    (1) If the code "452 insufficient system storage" is returned, the
  240.        client should next send either a RSET command (if it wishes to
  241.        attempt to send other messages) or a QUIT command. The client
  242.        should then repeat the attempt to send the message to the server
  243.        at a later time.
  244.  
  245.    (2) If the code "552 message exceeds fixed maximum message size" is
  246.        received, the client should immediately send either a RSET
  247.        command (if it wishes to attempt to send additional messages),
  248.        or a QUIT command.  The client should then declare the message
  249.        undeliverable and return appropriate notification to the sender
  250.        (if a sender address was present in the MAIL command).
  251.  
  252.    A successful (250) reply code in response to the extended MAIL
  253.    command does not constitute an absolute guarantee that the message
  254.    transfer will succeed.  SMTP clients using the extended MAIL command
  255.    must still be prepared to handle both temporary and permanent error
  256.    reply codes (including codes 452 and 552), either immediately after
  257.    issuing the DATA command, or after transfer of the message.
  258.  
  259. 5.3  Messages larger than the declared size.
  260.  
  261.    Once a server has agreed (via the extended MAIL command) to accept a
  262.    message of a particular size, it should not return a 552 reply code
  263.    after the transfer phase of the DATA command, unless the actual size
  264.    of the message transferred is greater than the declared message size.
  265.    A server may also choose to accept a message which is somewhat larger
  266.    than the declared message size.
  267.  
  268.    A client is permitted to declare a message to be smaller than its
  269.    actual size.  However, in this case, a successful (250) reply code is
  270.    no assurance that the server will accept the message or has
  271.    sufficient resources to do so.  The server may reject such a message
  272.    after its DATA transfer.
  273.  
  274. 5.4  Per-recipient rejection based on message size.
  275.  
  276.    A server that implements this extension may return a 452 or 552 reply
  277.    code in response to a RCPT command, based on its unwillingness to
  278.    accept a message of the declared size for a particular recipient.
  279.  
  280.  
  281.  
  282. Klensin, Freed & Moore                                          [Page 5]
  283.  
  284. RFC 1653                 SMTP Size Declaration                 July 1994
  285.  
  286.  
  287.    (1) If a 452 code is returned, the client may requeue the message for
  288.        later delivery to the same recipient.
  289.  
  290.    (2) If a 552 code is returned, the client may not requeue the message
  291.        for later delivery to the same recipient.
  292.  
  293. 6.  Minimal usage
  294.  
  295.    A "minimal" client may use this extension to simply compare its
  296.    (perhaps estimated) size of the message that it wishes to relay, with
  297.    the server's fixed maximum message size (from the parameter to the
  298.    SIZE keyword in the EHLO response), to determine whether the server
  299.    will ever accept the message.  Such an implementation need not
  300.    declare message sizes via the extended MAIL command.  However,
  301.    neither will it be able to discover temporary limits on message size
  302.    due to server resource limitations, nor per-recipient limitations on
  303.    message size.
  304.  
  305.    A minimal server that employs this service extension may simply use
  306.    the SIZE keyword value to inform the client of the size of the
  307.    largest message it will accept, or to inform the client that there is
  308.    no fixed limit on message size.  Such a server must accept the
  309.    extended MAIL command and return a 552 reply code if the client's
  310.    declared size exceeds its fixed size limit (if any), but it need not
  311.    detect "temporary" limitations on message size.
  312.  
  313.    The numeric parameter to the EHLO SIZE keyword is optional.  If the
  314.    parameter is omitted entirely it indicates that the server does not
  315.    advertise a fixed maximum message size.  A server that returns the
  316.    SIZE keyword with no parameter in response to the EHLO command may
  317.    not issue a positive (250) response to an extended MAIL command
  318.    containing a SIZE specification without first checking to see if
  319.    sufficient resources are available to transfer a message of the
  320.    declared size, and to retain it in stable storage until it can be
  321.    relayed or delivered to its recipients.  If possible, the server
  322.    should actually reserve sufficient storage space to transfer the
  323.    message.
  324.  
  325. 7. Example
  326.  
  327.    The following example illustrates the use of size declaration with
  328.    some permanent and temporary failures.
  329.  
  330.       S: <wait for connection on TCP port 25>
  331.       C: <open connection to server>
  332.       S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
  333.       C: EHLO ymir.claremont.edu
  334.       S: 250-sigurd.innosoft.com
  335.  
  336.  
  337.  
  338. Klensin, Freed & Moore                                          [Page 6]
  339.  
  340. RFC 1653                 SMTP Size Declaration                 July 1994
  341.  
  342.  
  343.       S: 250-EXPN
  344.       S: 250-HELP
  345.       S: 250 SIZE 1000000
  346.       C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
  347.       S: 250 Address Ok.
  348.       C: RCPT TO:<ned@innosoft.com>
  349.       S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
  350.       C: RCPT TO:<ned@ymir.claremont.edu>
  351.       S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
  352.       C: RCPT TO:<ned@hmcvax.claremont.edu>
  353.       S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
  354.       C: DATA
  355.       S: 354 Send message, ending in CRLF.CRLF.
  356.        ...
  357.       C: .
  358.       S: 250 Some recipients OK
  359.       C: QUIT
  360.       S: 250 Goodbye
  361.  
  362. 8. Security Considerations
  363.  
  364.    The size declaration extensions described in this memo can
  365.    conceivably be used to facilitate crude service denial attacks.
  366.    Specifically, both the information contained in the SIZE parameter
  367.    and use of the extended MAIL command make it somewhat quicker and
  368.    easier to devise an efficacious service denial attack.  However,
  369.    unless implementations are very weak, these extensions do not create
  370.    any vulnerability that has not always existed with SMTP. In addition,
  371.    no issues are addressed involving trusted systems and possible
  372.    release of information via the mechanisms described in this RFC.
  373.  
  374. 9.  Acknowledgements
  375.  
  376.    This document was derived from an earlier Working Group draft
  377.    contribution.  Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear,
  378.    Marshall T. Rose, and Einar Stefferud provided extensive comments in
  379.    response to earlier drafts of both this and the previous memo.
  380.  
  381. 10.  References
  382.  
  383.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  384.        USC/Information Sciences Institute, August 1982.
  385.  
  386.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  387.        Messages", STD 11, RFC 822, UDEL, August 1982.
  388.  
  389.    [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
  390.        Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
  391.  
  392.  
  393.  
  394. Klensin, Freed & Moore                                          [Page 7]
  395.  
  396. RFC 1653                 SMTP Size Declaration                 July 1994
  397.  
  398.  
  399.    [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
  400.        Headers", RFC 1522, University of Tennessee, September 1993.
  401.  
  402.    [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
  403.        "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
  404.        Consulting, Inc., Network Management Associates, Inc., Silicon
  405.        Graphics, Inc., July 1994.
  406.  
  407.    [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  408.        974, BBN, January 1986.
  409.  
  410. 11.  Chair, Editor, and Authors' Addresses
  411.  
  412.    John Klensin, WG Chair
  413.    MCI Data Services Division
  414.    2100 Reston Parkway, 6th floor
  415.    Reston, VA 22091
  416.    USA
  417.  
  418.    Phone:: 1 703 715 7361
  419.    Fax: +1 703 715 7435
  420.    EMail: klensin@mci.net
  421.  
  422.  
  423.    Ned Freed, Editor
  424.    Innosoft International, Inc.
  425.    1050 East Garvey Avenue South
  426.    West Covina, CA 91790
  427.    USA
  428.  
  429.    Phone:: +1 818 919 3600
  430.    Fax: +1 818 919 3614
  431.    EMail: ned@innosoft.com
  432.  
  433.  
  434.    Keith Moore
  435.    Computer Science Dept.
  436.    University of Tennessee
  437.    107 Ayres Hall
  438.    Knoxville, TN 37996-1301
  439.    USA
  440.  
  441.    EMail: moore@cs.utk.edu
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Klensin, Freed & Moore                                          [Page 8]
  451.  
  452.